-
Notifications
You must be signed in to change notification settings - Fork 5
chore: Rework CodeViewer to Extract Trigger Button & Remove showInlineContent
#1527
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
541ae4c to
dd7fc57
Compare
8737a95 to
73c5435
Compare
13b3154 to
a243c75
Compare
73c5435 to
73e7131
Compare
a243c75 to
1139464
Compare
73e7131 to
2a0ccca
Compare
1139464 to
1dd8730
Compare
2a0ccca to
f8e3134
Compare
1dd8730 to
0e92bae
Compare
f8e3134 to
e677909
Compare
19707ab to
726344b
Compare
65234bf to
7617cac
Compare
726344b to
5b89d37
Compare
7617cac to
c74095b
Compare
5f2112e to
0d02f62
Compare
a5ce09e to
47f036b
Compare
ed9558d to
1bccc0a
Compare
47f036b to
661532b
Compare
1bccc0a to
3c509e0
Compare
661532b to
eba55a1
Compare
3cf9d11 to
1d430eb
Compare
Mbeaulne
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey! I'm not sure I follow the benefit of this refactor. What's the use case for controlling fullscreen externally?
To me, fullscreen feels like an internal concern of the code viewer - user clicks the button, it goes fullscreen. I don't see when we'd need the parent to manage that state.
Breaking it up means more wiring every time we use it, and it spreads related logic across components. Unless there's a specific need I'm missing, I'd prefer to keep the code viewer self-contained.
What's driving this change?
|
@Mbeaulne I discussed the remainder of this stack with @maxy-shpfy this morning and we are going to try a different approach. I am going to put the rest of the stack into draft while exploring & then probably close these PRs. |
1d430eb to
09b0dc1
Compare
448e775 to
950e030
Compare
|
@Mbeaulne I have reworked this PR. Fullscreen functionality is no longer extracted from the Code Viewer and remains a concern of the code viewer itself. This simplifies things greatly. The objective is to remove What I've done now is rework the component to accept a |
showInlineContent
maxy-shpfy
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
950e030 to
260200e
Compare
260200e to
84c3fc7
Compare

Description
Rework the
CodeViewerso the inline trigger button for fullscreen-only is not embedded into the CodeViewer component itself. More specifically, this PR targets the removal of theshowInlineContentprop.The
showInlineContentprop turnsCodeViewerinto a button that opens the actual code viewer component in fullscreen. This paradigm does not make much sense and is restrictive. e.g. we currently cannot open the codeviewer in fullscreen via a callback.This PR removes
showInlineContentand the related button, instead extracting that button into a newViewYamlButtonwhich can be reliably used anywhere in the app. The component now focusses on rendering the code viewer UI. The introduction of afullscreenprop allows us to force it to render in fullscreen-mode only, like the originalshowInlineContentwas doing. The existing behaviour in non-fullscreen mode is unchanged (it can still toggle fullscreen at will).Note: I didn't want to get bogged down with trying to move all the
divs in CodeViewer onto BlockStack. I feel that given it's a bespoke component it's probably okay for now to leave as-is. I did, however, clean up a couple of icons and css.Related Issue and Pull requests
Type of Change
Checklist
Screenshots (if applicable)
No change to app functionality. Code architecture update only. Confirm that the CodeViewer still behaves exactly as expected.
Test Instructions
Additional Comments